(logo)  Cache usage

Why a cache is useful

When you are web-surfing, you often find that there are pages that you visit every time again. Most of the time these pages haven't changed, so it is really a waste of network bandwidth to fetch the page (and possibly the images on it) every time. The cache is used to store the most recently visited pages and images on your hard disk. The next time you visit the same page, it is already on your computer. There is no need to retrieve it again over the network, thus saving time and bandwidth.

Another benefit of having a cache is, that after you have disconnected from the network, the pages remain on your computer. You can then browse through them again off-line.

How the cache works

AWeb uses a two-stage caching system, both in memory and on disk. The main cache is on disk, and for the most recently used objects there is also a copy in memory. This way you will always get the maximum response speed.
The term "object" is used here to indicate documents (pages) and inlined images shown within documents.

Whenever you click a link (or type an URL), or an embedded image on a page is needed, AWeb first looks in its cache to see if it is already there. If the object is in memory, it is used immediately. If it is still on disk but not in memory, it is loaded back into memory. If it is not on disk, it is fetched over the network.

A reload of an object never uses the cached copy, but fetches the object from the original location again.

Verifications

Of course, if the original object has been updated since it was stored in the cache, the cache copy should be updated as well. Therefore, when AWeb uses a cached copy of an object, it also sends a verification request to the server, to see if the object was modified. If not, AWeb will use the cache copy, and if the object is modified, AWeb will fetch the new version.

You can control how often AWeb will check with the server:

· Verify always

Every time AWeb uses an object from the cache, it will also send out a verification request. This guarantees that you always see the most recent version. Obviously it also generates a lot of network activity, so normally you won't use this. Only if you visit sites with many documents that are updated very frequently you may want to use this option.

· Verify once per session

Only when AWeb uses an object from the cache for the first time after you started AWeb, it will check with the server. The second and later times the object is used without verification. This allows AWeb to update its cached objects regularly, but does not produce excessive network overhead. This is the default verification mode.

· Verify never

AWeb will just use cached copies of objects if they are available. It will never check with the server if the object has changed. If you know or suspect that the cached copy is no longer up-to-date, you should use the reload function.

When you browse off-line through cached pages with AWeb set to one of the other response modes, AWeb silently falls back to verify never mode. So it won't complain that it cannot connect to the server, and won't try to start your TCP stack just to verify cached objects. Of course it will do so when you try to fetch an object that is not in cache.

Fast response

Most browsers implement the verification mentioned above so that they first ask the server, and when the object turns out to be unmodified, then they use the cached copy. As a consequence, with every link you follow, you have to wait a few seconds until the network connection is set up and the server responds. You have to wait with every verification, even if the object is still in cache and up-to-date.

In most cases, the cached copy will still be valid. After all, that is one of the reasons for having a cache in the first place. So slow verification will let you wait many times totally unnecessary.

When using fast response mode, AWeb always uses the cached copy if one is available. The cached document or image is displayed immediately. In the same time that the object is displayed, AWeb connects to the server and verifies if the object is indeed not modified. In most cases the copy will still be up-to-date, and these connections disappear silently after a few seconds. This way you will gain a few seconds with every link you follow to a cached document.

In the few cases where the object was modified, you will first see the old version that was in cache. Then after a few seconds, when the server responds, the new updated version will be shown in the window, much like as if you had hit the reload button.
If this behaviour confuses you or annoys you, you should not use fast response mode.

Uncached objects

All documents and inlined images from the net are stored in the cache. The following objects will not go into the cache:

Cache directory

To take maximum advantage of AWeb's cache, the cache directory should be located on your hard disk. It is possible to configure AWeb to use a drawer in your Ram disk for its cache, but that would take up much memory and everything will be lost when you turn off your machine.

Should your machine crash (or be turned off) while AWeb was still active, then the next time you start AWeb the cache will be recovered automatically.

AWeb stores its cache files in several subdirectories. That way the number of files in each directory is kept low, which will result in a much faster cache when used with certain file systems (like AFS).

Note that you should not use the cache directory for anything else. Also, don't modify or delete any files.
If you accidentally deleted some files from the cache, or if you suspect that it has become corrupt, you should use the Cache / Fix cache... menu item. It will synchronize the internal registration with the files actually on disk. NOTE: This function will delete any files from the cache directory that are not belonging to AWebs cache.

Cachebrowser

You can use the cachebrowser to see what files are in the cache, and optionally view, save or delete them.

<- Back to index.